Atari Mega Archive 1/Atari Mega Archive - Volume 1.iso/lists/gem/l_1199/823

Internet Message Format | 1994-08-27 | 10.8 KB

Date: Sun, 17 Jul 1994 13:08:34 -0400 (EDT)
Date: Wed, 13 Jul 94 00:45 EST
Subject: Gem List (fwd)
Subject: Gem List
Subject:  Re: Gem List (fwd)
Subject:  Digest
Subject:  Re: Gem List (fwd)
Date: Sun, 17 Jul 1994 13:08:34 -0400 (EDT)
Mime-Version: 1.0
Precedence: bulk

Forwarded message:
>From [e-mail] Wed Jul 13 04:50:13 1994
Date: Wed, 13 Jul 94 00:45 EST
From: "Daniel J. Hollis" <[e-mail]>
To: ems <[e-mail]>
Subject: Gem List
Message-Id: <10940713054501/[e-mail]>

TO: [e-mail]
Subject:  Re: Gem List (fwd)

Chris:
------
> From the sound of the following flame-bait, you have no idea how object-
> oriented programming works.

An attempt at dodging the question, eh? Hmm, typical.

I have worked with obj
ect-oriented programming on the Atari, and I can say
it's not hard.  Also, I am writing a GUI library in which I am *DESIGNING*
my own object oriented design.  So don't tell me that I have no idea that I
don't know how to do OOP, because I can tell you th
at I do.

> Nothing is a pain with GEM++...  ;-)

Okay, you tell me a *single* command that lets you do sliders without having
to handle it yourself.

> OOP is mainly customizing objects for your own use, once the library is
> finished, that is.

Customi
zing objects for your own use... spending time piecing a library
together to do simple things, rather than having a library pre-written
which 'does it all for you'?

Sounds like some of us enjoy re-inventing the wheel.

> Warwick built GEM++ from scratch,
 so he did all the hard work.  Now if _I_
> use GEM++ for a dialog-in-a-window or something, it takes about 5 lines of
> code.

Ooh, so I guess it's the *best* library out there from the way you speak?
In WinLIB PRO, dialog-in-a-window takes all of 3 line
s of code. But from the
way you're talking, I guess 5 lines of Gem++ code to support
dialog-in-a-window must mean it's better or something?

The three lines of code required in WinLIB PRO are:

int TitleDispatcher(WINDOW *win, int msg_buf[8])
{
    return FA
LSE;
}

WCreateWindow(W_DIAL, 0, NAME|CLOSER|MOVER, "Title dial", NULL,
              -1, EDIT1, -1, TitleDispatcher, 0, -1, -1, -1, -1, editdial,
               D_SWITCHABLE);
WDoDial(NULL);

There. That was really difficult wasn't it? Now with the new w
indow installed,
it WinLIB PRO handles the dialog, lets you move it, BACKGROUND click buttons
with the LEFT mouse button (and not some LAME left-right button simultaneous
click, I might add) and close it. WinLIB PRO handles everything for you when
you ret
urn a FALSE in the window dispatcher code.

> I don't have to do anything special to
> the dialog in the RSC editor, and the code I _do_ write for my dialog
> is exactly what I'd have to write for a normal dialog... something to
> figure out what switches
 were set, what exit button was pushed, etc.

Gheez, like that's hard to code or something? So how do you set an
'active slider' in Gem++ without using special code (since you said you
don't write any special support code for it) and without doing anythin
g
special to the RSC with a RSC editor (ooh mommy, changing the extended
object type is soooo hard!)

> That's a "feature" of not having an up-to-date RSC editor that can build
> RSC objects for the new AES.  If they'd built one of those, adding the
> hie
rarchical menus in a saner way would've been easy.

Yes, but now that there are editors available to do this, then it should not
be too hard to do this... let's see... any number of PD resource editors have
been able to change extended object types for YE
ARS now. Of course, it seems
that some people are living in the past, using obsolete tools (maybe you? :-)

> And possibly a complete re-build of your entire application so you can
> use the new extended-GEM library headers and link it with the new librar
y.

Not so. To change a WinLIB PRO object from a normal slider to an active
slider requires *no* code changes, just a dip into the RSC file to change
the extended object type. You can design entire heirarchical menus in the RSC
editor without having to to
uch a line of code. Can the same be said of Gem++?

>From the consistent evasions of my questions, it's obvious you know nothing
about extended object types. (And yes, I fully expect you will dodge this
statement with yet more doublespeak).

> I guess you'
ve never compared the GUI code for an *application* using GEM++
> to that built with a "normal" library...

That's true. Because there *ARE* no applications written using Gem++.

> 1) They're afraid of GNU C/C++, since it's not a commercial product.

Wron
g. I have no problems with using PD compilers. The reason I stay away
from Gnu C/C++ is that I don't have the resources to waste (i.e. tons of RAM,
and tons of diskspace). And the fact that Gnu C++ spits out binaries roughly
5 to 20 times bigger than the
*same code* in Pure C.

> 2) There's no commercial C++ implementation for the Atari.

So?  The Atari's dead, anyway.

> 5) Their ST is too damn slow for C++ development.

I think you answered your own question there. Not everyone has a TT. Or
even a Falco
n030. Reason #5 is why everyone is using C!

> 6) Their ST doesn't have enough RAM for C++ development (it gets _really_
>    tight in 4M of RAM).

That's exactly the main reason why I shy away from using any type of C++ on
the Atari ST, because of the EN
ORMOUS resource requirements.

A Boeing 747 (Gnu C++) may be able to carry the most passengers at once,
but it's not necessarily the best choice for all pilots. Some of us are
perfectly happy with our small, speedy, agile F-15's (Pure C). :-)

> 7) Their
ST doesn't have a hard drive (!), which is pretty necessary
>    for GNU C/C++, since the compiler is over a meg in size.

Tell me ONE person who isn't a programmer and is sane enough NOT to use a
hard drive. Despite the fact that development is quite pos
sible with
PureC and floppies, and quite impossible with GnuC++ and floppies. :-)

--Ken Hollis (Bitgate Softwate)
-----
Subject:  Digest

> Your code only works if the event loop includes a timer event of very small
> duration. In which case it slows it
 down by having this code running regularly.
> Fine in a single-tasking system, but it will slow down background tasks.

No, it works even if the event loop is very large, too. It's just much
slower :-)

Background tasks are *meant* to be less responsive
than the foreground
task. Otherwise there would be no distinction between the two. :-)

> Why would you want to make a new broadcast message? And I can't think of any
> reason for a new wind_set/get mode.

Who said anything about a new broadcast message?
 IF you wanted to create your
own broadcast message, you should register it so other programmers knew how
to use them.

> it really does replace the aes. It doesn't, however replace the kernel.

Wrong.  It doesn't replace the AES.  Geneva, like Let 'em Fl
y, hooks AES
calls on to the already made AES calls, and intercepts existing routines.
That's why Geneva behaves like it does, and has the limitations it does.

Of course, had you actually bothered to CHECK this before spewing that
statement out, you coul
d have saved yourself the humiliation of being WRONG.

Better yet, break out a debugger and check things out for yourself. You DO
know how to use an assembler-level debugger do you not?

> Since it is cooperative multitasking how can you say it gives one
application
> 25% or 50% of the CPU time anyway?

>From experience, and extensive testing. Two things which you seem to have
little of.
-----
Subject:  Re: Gem List (fwd)

Warwick:
--------
>>>If you use a 1-pixel rectangle, then EVERY mouse movement goes
 back to
>>>your program, and your program has to do an objc_find, EVERY TIME.
>>We're not using "1 pixel rectangles" like you seem to enjoy saying alot :-)
>>You can get the current mouse pointer coordinates by any method you like --
>>as you will see i
n the example code, that part was specifically left "open".
>1-pixel rectangles is the most efficient method.  Of course, your code
>would probably have a 0ms timer event!  Horror of horrors!  [do you use
>MTOS?]

I've used MTOS enough to be disgusted wit
h it. It's a piece of crap. Slow,
and inefficient.

WinLIB PRO supports all MTOS messages, and with WinX and normal TOS we can
support almost all the AES 4.* stuff, and do it *faster* -- without having
the overhead of dragging MiNT along with us when it's
 not needed.

Our multitasking design *requires* that we have a 0ms timer event, since
we allow multiple threads of execution within one GEM program, even without
MultiTOS. You are free to use slower timer events, but your subthread
performance will suffe
r.

>>You have to understand how GEM works before you can bring up an argument
>>like this.
>I *do* understand how GEM works.  Stop these sarcastic comments NOW.

Evade evade... dodge dodge.. you seem to be rather good at that.

>>There is another problem
 here -- our library allows you to set multiple
>>timer events and 'attach' them to windows. If we set our event_timer to
>>wait for rectangle events, then the timers would become effectively
>>useless. The library does need to do events on a regular basi
s, but only
>>mouse events will be done if the application is TOPPED.
>GEM doesn't work that way.  You wait for multiple events, and if a timer
>event expires first, then you process that, then continue waiting for
>rectangle events, and whatever other ev
ents (such as more timer events).

So, you're saying we NEED to watch for mouse rectangle events when our
application is not topped? That makes very little sense at all.

>>Warwick, are you SURE you understand what Extended Object Types are?  From
>>the w
ay you speak, it sounds like you have no idea why they were designed.
>More sarcasm.  Ignored.

Lame attempt at evasion of the question (as usual). I ask again, do you
understand what extended object types are?

>You're saying that with Gem++ you would ha
ve to add code to support the
>active slider, perhaps doing something like "register_active_slider(TREE,
>object, orientation);" which is insane. Having to write code to support
>an interface when the interface should do those things ITSELF is a pain.
>Yo
u have to attach the slider to some other components, eg. make them
>control something, so you have to do some form of registration anyway.
>(In GEM++, it is constructing objects).

Wrong. You do not "have" to do this. The slider in WinLIB PRO is define
d by
its relation in the object tree to its parent object, and its extended object
type. There is *NO* reason whatsoever that you have to "attach" a child
object to its parent with some code to make it an active slider. In a good
library, this should be a
n inherent property from the structure of the RSC
file.

>>If you want to make a quick change to your interface, with Gem++ you would
>>have to recompile the code. With all other libraries it's just a quick dip
>>into a resource editor to make that change